Speci cation of Tools with GTSL

INCREMENT INTERFACE ScopingBlock; INCREMENT SPECIFICATION ScopingBlock; INHERIT Increment; INITIALIZATION ... DefinedNames := NEW DuplicateSymbolTable; SEMANTIC RELATIONSHIPS END INITIALIZATION; IncludedNames:IMPLICIT SET OF DefiningName.Block SEMANTIC RULES END SEMANTIC RELATIONSHIPS; ON EXISTS(name:DefiningName IN IncludedNames): CHANGED(name.value) ATTRIBUTES ACTION DefinedNames:SymbolTable; SELF.DefinedNames.associate(name,name.value); END ATTRIBUTES; END ACTION; ... END INCREMENT INTERFACE ScopingBlock; ON EXISTS(name:DefiningName IN IncludedNames): DELETED(name); ACTION SELF.DefinedNames.deassociate(name,name.value); END ACTION; END SEMANTIC RULES; END INCREMENT SPECIFICATION ScopingBlock. Figure 3: Abstract Increment Class ScopingBlock the semantic rule below res and inserts or deletes an error descriptor into or from an error set. This error set is consulted during the computation of the external representation in order to visualise erroneous increments by underlining. The particular error descriptor to be inserted upon detection of an error is language-speci c and is determined by rede nition of a deferred method in the language-speci c subclasses. ABSTRACT INCREMENT INTERFACE DefiningName; INCREMENT SPECIFICATION DefiningName; INHERIT Increment; INITIALIZATION ... Block := SELF.myScope(); SEMANTIC RELATIONSHIPS END INITIALIZATION; Block:ScopingBlock; UsedBy:IMPLICIT SET OF SEMANTIC RULES UsingName.DefinedIn ON CHANGED(Block.DefinedNames) END SEMANTIC RELATIONSHIPS; ACTION IF(SELF.Block.DefinedNames.is_dupl(SELF)) THEN METHODS SELF.Errors.append_error(SELF.ErrorId()); METHOD myScope():ScopingBlock; ELSE DEFERRED METHOD ErrorId():ERROR; SELF.Errors.clear_error(SELF.ErrorId()); END METHODS; ENDIF ... END ACTION; END INCREMENT INTERFACE DefiningName; END SEMANTIC RULES; END INCREMENT SPECIFICATION DefiningName. Figure 4: Abstract Increment Class DefiningName In many languages that occur in software engineering practice, applied occurrences of names must match a declaration. This property is de ned by a semantic rule in class UsingName as depicted in Figure 5. The pre-condition of the rule depends the symbol table of the scoping block determined by link Block. The link is established in the same way as above, but this is for reasons of brevity omitted. The rule also depends on the lexical value of the changed name. Whenever any of these are changed, a symbol table lookup is performed in order to 12 store a matching declaration in the local variable inc. If inc is not NIL, a match has been found. We then have to obtain, whether the declaration is of the right type. In our interface editor, for instance the use of operation names as parameter or result types is inhibited. This is again language-speci c and determined by the deferred method DeclClass that must be rede ned in all subclasses. If the increment is of the right class, the semantic relationship DefinedIn/UsedBy is established and a language-speci c error descriptor, determined by the deferred method ErrorId, is deleted from the set of errors. In the other case the semantic relationship is deleted and the error descriptor is inserted into the set. ABSTRACT INCREMENT INTERFACE UsingName; INCREMENT SPECIFICATION UsingName; INHERIT Increment; ... ... SEMANTIC RULES ON CHANGED(Block.DefinedNames) SEMANTIC RELATIONSHIPS OR CHANGED(value) DefinedIn:DefiningName; VAR inc: Increment; Block:ScopingBlock ACTION END SEMANTIC RELATIONSHIPS; inc:=Block.DefinedNames.increment_at(value); IF inc != NIL THEN METHODS IF( inc.IS_KIND_OF(SELF.DeclClass())) THEN DEFERRED METHOD DeclClass():STRING; DefinedIn := inc; DEFERRED METHOD ErrorId():ERROR; Errors.clear_error(SELF.ErrorId()); ... ELSE END METHODS; DefinedIn:=NIL; END INCREMENT INTERFACE UsingName; Errors.append_error(SELF.ErrorId()); ENDIF; ELSE DefinedIn:=NIL; Errors.append_error(SELF.ErrorId()); ENDIF; END ACTION; END SEMANTIC RULES; END INCREMENT SPECIFICATION UsingName. Figure 5: Abstract Increment Class UsingName These classes have been reused in various tools to specify name analysis. In the module interface editor, Module is for instance a subclass of ScopingBlock and thus implements a new scope. TypeName and TypeImport are classes that inherit from DefiningName, while UsingType inherits the semantic rule from UsingName. In these subclasses only the deferred methods are rede ned in order to determine the language-speci c properties. Interactions: The steps of a software development method are implemented by the commands that the tool o ers. The command de nition determines the names of commands, pre-conditions for their applicability and the particular dialogues between tool and user, if any. In GTSL commands are de ned as interactions. The de nition of an interaction encompasses an internal and an external name, a selection context, a precondition and an action. The external name appears in context sensitive menus or is used to invoke a command from a command-line. The internal name is used to determine the rede nition of an inherited interaction. The selection context de nes which increment must be selected so that the interaction is applicable. It is actually included in a context-sensitive menu if the precondition that follows the ON clause evaluates to TRUE. The action is a list of GTSL statements that is executed as soon as the user chooses the command from the menu. 13 The interaction displayed in Figure 6 is considered to be o ered if the selected increment is a type name. It is actually o ered if the type has already been expanded. If this is the case and the user has requested a menu, the string Change Type will become a menu item. If the user chooses this item, the action is executed and the user will be prompted to edit the type identi er in a line edit window. The default character string in this line edit window is the value of the old type identi er. If the dialogue is completed, the LINE EDITmethod returns TRUE and the method scan is executed. The method implementation is generated from a regular expression that is provided for terminal increment classes. It returns TRUE if the identi er is lexically correct, otherwise it returns FALSE. If the identi er is correct the two semantic relationships of a type name are exploited to propagate the change to dependent increments such as parameter types or type imports in order to retain consistency. Then the new lexical value is stored in attribute value. If the identi er is wrong an appropriate error message is displayed. Multiple users cannot concurrently execute commands in a totally unrestricted way. This is due to the lost update and inconsistent analysis problems, known from concurrency control in database systems [Dat86]. As an example of the inconsistent analysis problem, consider the following scenario. A designer uses the above interaction to change the name of an exported type. A concurrently working designer creates an import statement referring to the old type. During that, the included type name is searched in the symbol table DefinedNames of the module where the type is being changed. An inconsistent analysis problem occurs if this search is performed after the other tool has done the change propagation and before the association was changed in the table. Then the import statement will not be displayed as inconsistent although the imported type does not exist anymore. The construction of an example for lost updates is straight-forward. Now we have encountered the dilemma that we cannot lock document versions exclusively while they are being edited without hampering cooperation. On the other hand, we must restrict concurrency to avoid the lost update and inconsistent analysis problems. The dilemma is solved by decreasing granularity with respect to both the subject that performs locking and the objects that are being locked. This means that tool sessions are considered as sequences of command executions, each of which is executed in isolation from concurrent commands. Isolation is achieved by locking objects in a traditional way [Gra78]. Locking is inferred from the use of objects and relationships and need not be speci ed explicitly. An object is locked in shared mode when the object is read and in exclusive mode when it is updated. While shared locks are compatible to each other, any other combination reveals a concurrency control con ict. To decrease the probability of concurrency control con icts, commands do not lock the complete representation of a document version, but only those nodes that are being accessed or updated during the execution of the command. In the examples that encounter lost updates or inconsistent analysis problems, we would then obtain a concurrency control con ict. Tools react to these con icts by delaying the execution of one command to await completion of the con icting command, that is until con icting locks have been released. This is appropriate because command execution requires only a few hundred milliseconds, which users will hardly recognise as delays. Apart from the isolation property sketched above, interactions have further transaction properties. They are atomic, i.e. they are either performed completely or not at all. Once completed, the e ect of an interaction is durable, i.e. all changes that were made during the interaction persist even if the tool is stopped accidentally by a hardware or software failure. Due to atomicity, tools then recover to the state of the last completed command execution. 14 INCREMENT SPECIFICATION TypeName; ... INTERACTIONS INTERACTION ChangeType NAME "Change Type" SELECTED IS SELF ON (SELF.expanded) VAR t:TEXT; err:TEXT_SET; BEGIN // start a new transaction t:=NEW TEXT(value); // read-lock SELF IF (t.LINE_EDIT("Enter New Type!")) THEN IF SELF.scan(t.CONTENTS()) THEN FOREACH i:TypeImport IN ExpTo DO i.react_to_change(t.CONTENTS()) ENDDO; FOREACH i:UsingType IN UsedBy DO i.react_to_change(t.CONTENTS()) ENDDO; value:=t.CONTENTS() // write-lock SELF ELSE err:=NEW TEXT_SET(SELF.get_errors()); // read-lock SELF err.DISPLAY; ENDIF ENDIF END ChangeType; // release all locks, make changes persistent Figure 6: Command De nition to Change a Type 4.3 External Document Representation The external document representation is determined in terms of unparsing schemes. Unparsing schemes are de ned for non-terminal increment classes only. They cannot be de ned for abstract increment classes. In that case abstract syntax children that might be added in subclasses would not be re ected. Neither are unparsing schemes required for terminal increment classes. For terminal increments the layout computation only needs to output the terminal increment's lexical value. As an example for a textual document representation consider the unparsing schemes of classes ADTModule and OperationList from the module interface editor below. The external representation of graphical documents must also de ne bitmaps or shapes of lines for increment representation purpose. NONTERMINAL INCREMENT INTERFACE ADTModule; NONTERMINAL INCREMENT INTERFACE OperationList ... ... UNPARSING SCHEME UNPARSING SCHEME "DATATYPE",WS,"MODULE",WS,name,";",(NL),(NL), ol DELIMITED BY (NL),(NL) END (" "),com,(NL),(NL), END UNPARSING SCHEME; (" "),"EXPORT",WS,"INTERFACE",(NL),(NL), (" "),"TYPE",WS,typ,";",(NL),(NL), (" "),op_list,(NL), (" "),imp,(NL),(NL), "END",WS,"MODULE",WS,name,".",(NL) END UNPARSING SCHEME; ... 15 5 Evaluation A compiler for GTSL has been implemented within the GOODSTEP project. It generates an object database schema for the O2 database system [BDK92], which is used for persistent storage of abstract syntax graphs following the strategy discussed in [EKS93]. A detailed discussion of the implementation is beyond the scope of this paper and we refer to [Emm95]. GTSL has been evaluated within GOODSTEP on the basis of requirements provided by British Airways, an industrial GOODSTEP partner. British Airways does most of its software development in-house, with an increasing number of projects using object-oriented techniques. A department of the IT infrastructure division, with seven developers at present, is supposed to design, implement and document class libraries for the purpose of corporate reuse. The evaluation scenario, which we refer to as BA SEE in the following, is an environment that supports this class library development and maintenance process. Figure 7: Tools Contained in the BA SEE Design documents of class libraries are de ned in the Booch notation [Boo91]. A Booch class diagram is structured into categories. A category may contain a number of classes and nested categories. The most recent de nition of the Booch notation is strongly tight towards C++, which is the programming language used for any object-oriented development at British Airways. Booch diagrams identify di erent kinds of relationships between classes, namely inheritance, hasand use-relationships. They have di erent C++ speci c adornments. Inheritance may, for instance, be public, protected or private. 16 The language used for class de nitions at British Airways is, in fact, only a subset of the C++programming language. The subset is determined by British Airways corporate programmingguidelines. The guidelines exclude C++ statements, such as ellipses, inlines and friends, whoseuse would be contrary to accepted software engineering principles. The dependencies of a classde nition document to other class de nitions are de ned in terms of #include statements andforward declarations.An implementation has to be provided for each de ned class. Therefore, a further documenttype includes C++ method implementations. Each method that has been de ned in a classinterface must be implemented in the respective class implementation document.Since class libraries are developed for corporate reuse, they must be accompanied by docu-mentation that allows customers to reuse classes from the library. Library customers require atechnical documentation of the functionality provided by the public and protected methods ofa class. This technical documentation is de ned in the information processing facility (IPF)language, a mark-up language for online-hypertexts de ned by IBM. For each class of thelibrary an IPF document must be provided. Besides the signatures of public and protectedmethods of the class, it also includes a description of each method and examples illustratinghow to use the methods. A hypertext, which can be compiled from an IPF document, is thendelivered to customers as an on-line help facility.The method integration de nes numerous inter-document consistency constraints between theabove documents. These are implemented by the tools contained in the environment. Eachclass in the Booch diagrammust be re ned in terms of a class de nition, an implementation andan IPF documentation. Upon creation of a class, the Booch editor creates these documentsas well. If a class name is changed, the Booch editor consistently changes the class namesin the corresponding documents. Moreover, the relationships that are de ned in the Boochdiagram must be re ected in the class de nition and implementation documents. The Boocheditor creates, for instance, the corresponding C++ declarations for an inheritance relationshipbetween two classes in the Booch diagram. Similarly, the integration of the three textual toolscauses the insertion of the respective counterparts into the corresponding implementation andIPF documents, upon creation of a method. Furthermore, the matching of method signaturesof the class de nition and their corresponding de nitions in the implementation and IPFdocuments is ensured.The number of classes required for a tool speci cation is dominated by the number of produc-tions in the grammar of the respective language. The C++ class de nition grammar consistsof 87 productions. 13 abstract classes were added to the non-terminal and terminal classesderived from the grammar to specify static semantics and inter-document consistency. Theaverage size of a class speci cation depends largely on the number of tool-speci c commandsthat have to be de ned. In the C++ class de nition tool a number of interactions had to bede ned in order to meet the speci c requirements of British Airways. The average size of aGTSL class was 2,730 Bytes. The complete C++ class de nition tool was de ned in a GTSLspeci cation with 9,800 lines or 273 KBytes.Compared to tools that can be bought of the shelf the environment has a number of advantages.Multiple users can access the same documents concurrently and immediately see each other'supdates. Versions and con gurations are not only managed for the source code, but alsofor Booch diagrams and IPF documentation. The tools enforce the corporate programmingguidelines. They check and even preserve the numerous inter-document consistency constraintsby change propagations.17 6 Summary and Further WorkWe have discussed the need for method de nition and integration. Method de nitions haveto identify document types. Method integration must de ne inter-document consistency con-straints. The application of methods should be supported by tools whose integration imple-ments the method integration. We then have discussed why documents should be consid-ered represented as project-wide abstract syntax graphs. Then we have outlined GTSL asa speci cation language capable to de ne these project-wide abstract syntax graphs as wellas commands that are o ered by tools to modify these graphs. GTSL has been used for theconstruction of an integrated development environment to support class library developmentand maintenance and we have sketched the evaluation results.A result of the evaluation was that there are often document types, like C++ class interfacesand the corresponding IPF documents whose structure is so similar that the documents shouldnot be stored redundantly. To improve e ciency and reduce the number of required changepropagations these documents should be considered as di erent views of the same conceptualsyntax graph. An extension of GTSL with language concepts to de ne di erent views has beendone and it is now being implemented on the basis of a view mechanism for object-orienteddatabases [SAD94].Di erent document versions can be managed on the basis of the version manager of the O2database system [DM93]. The problem of con guration management has not yet been su -ciently addressed. Semantic relationships with other document versions are established duringediting as determined by the semantic rules. They are, however, only created with those otherversions of documents that have either been selected explicitly or are the default version. Inthat way a user accesses exactly one con guration at a time. What is not yet supported is theexplicit construction of a con guration. To facilitate this, tools would have to compute theset of document versions that are consistent with each other. This obviously interferes withevaluation of semantic rules and it is not clear to us when the required evaluations can bestbe done.AcknowledgementsWe received considerable feedback on the appropriateness of GTSL during the constructionof the BA SEE. I, therefore, thank Jim Arlow and Mark Phoenix from British Airways forexposing us to tool requirements from an industrial perspective. I thank a number of students,namelyWerner Beckmann, Joerg Brunsman, Boris Gesell, Jens Jahnke, Matthias Kurth, RalphMertingk and Wiebke Reimer who contributed to the implementation of the GTSL compiler.I thank Prof. Uwe Kastens, Prof. Carlo Ghezzi and Prof. Wilhelm Schafer for the discussionswe had on GTSL. The presentation of this paper was improved by valuable comments that Igot from Dr. Willi Hasselbring on an earlier draft.References[ASU86]A. V. Aho, R. Sethi, and J. D. Ullmann. Compilers { Principles, Techniquesand Tools. Addison Wesley, 1986.18 [BDK92] F. Bancilhon, C. Delobel, and P. Kanellakis. Building an Object-OrientedDatabase System: the Story of O2. Morgan Kaufmann, 1992.[Boe88]B. W. Boehm. A Spiral Model of Software Development and Enhancement.IEEE Computer, pages 61{72, May 1988.[Boo91]G. Booch. Object Oriented Design with Applications. Benjamin/Cummings,1991.[Dat86]C. J. Date. Introduction to Database Systems, Vol. 1. Addison Wesley, 1986.[DGKLM84] V. Donzeau-Gouge, G. Kahn, B. Lang, and M. Melese. Document structure andmodularity in Mentor. ACM SIGSOFT Software Engineering Notes, 9(3):141{148, 1984. Proc. of the ACM SIGSOFT/SIGPLAN Software Engineering Sym-posium on Practical Software Development Environments, Pittsburgh, Penn.[dM78]T. de Marco. Structured Analysis and System Speci cation. Yourdan, 1978.[DM93]C. Delobel and J. Madec. Version Management in O2. Technical report, O2-Technology, 1993.[EKS93]W. Emmerich, P. Kroha, andW. Schafer. Object-oriented Database ManagementSystems for Construction of CASE Environments. In V. Marik, J. Lazanksy, andR. R. Wagner, editors, Database and Expert Systems Applications | Proc. of the4th Int. Conf. DEXA '93, Prague, Czech Republic, volume 720 of Lecture Notesin Computer Science, pages 631{642. Springer, 1993.[ELN+92] G. Engels, C. Lewerentz, M. Nagl, W. Schafer, and A. Schurr. Building Inte-grated Software Development Environments | Part 1: Tool Speci cation. ACMTransactions on Software Engineering and Methodology, 1(2):135{167, 1992.[ELS87]G. Engels, C. Lewerentz, and W. Schafer. Graph-grammar engineering: A Soft-ware Speci cation Method. In Proc. of the 3rd Int. Workshop on Graph Gram-mars and their Application to Computer Science, volume 291 of Lecture Notesin Computer Science, pages 186{201. Springer, Berlin, 1987.[Emm95] W. Emmerich. Tool Construction for Process-Centered Software DevelopmentEnvironments based on Object Database Systems. PhD thesis, University ofPaderborn, Germany, 1995. Forthcoming.[ES94]W. Emmerich and W. Schafer. Groupie | An Environment supporting Group-Oriented Architecture Development. Technical Report 71, University of Dort-mund, Dept. of Computer Science, Chair for Software Technology, 1994. Sub-mitted for Publication.[GMT87] F. Gallo, R. Minot, and I. Thomas. The Object Management System of PCTEas a Software Engineering Database Management System. ACM SIGPLAN NO-TICES, 22(1):12{15, 1987.[Gra78]J. N. Gray. Notes on Database Operating Systems. In R. Bayer, R. Graham,and G. Seegmuller, editors, Operating systems { An advanced course, volume 60of Lecture Notes in Computer Science, chapter 3.F., pages 393{481. Springer,1978.19 [HN86]A. N. Habermann and D. Notkin. Gandalf: Software Development Environments.IEEE Transactions on Software Engineering, 12(12):1117{1127, 1986.[Hoo87]R. Hoover. Incremental graph evaluation. PhD thesis, Cornell University, Dept.of Computer Science, Ithaca, NY, 1987. Technical Report No. 87-836.[JF82]G. F. Johnson and C. N. Fisher. Non-syntactic attribute ow in language basededitors. In Proc. of the 9th Annual ACM Symposium on Principles of Program-ming Languages, pages 185{195. ACM Press, 1982.[Knu68]D. E. Knuth. Semantics of Context-Free Languages. Mathematical SystemsTheory, 2(2):127{145, 1968.[KW91]U. Kastens and W. M. Waite. An abstract data type for name analysis. ActaInformatica, 28:539{558, 1991.[Nag85]M. Nagl. An Incremental and Integrated Software Development Environment.Computer Physics Communications, 38:245{276, 1985.[Par72]D. C. Parnas. A Technique for the Software Module Speci cation with Examples.Communications of the ACM, 15(5):330{336, 1972.[RBP+91] J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy, and W. Lorensen. Object-Oriented Modeling and Design. Prentice Hall, 1991.[Roy70]W. W. Royce. Managing the Development of Large Software Systems. In Proc.WESCON, 1970.[RT81]T. W. Reps and T. Teitelbaum. The Cornell Program Synthesizer: A syntax-directed programming environment. Communications of the ACM, 24(9):449{477, 1981.[RT84]T. W. Reps and T. Teitelbaum. The Synthesizer Generator. ACM SIG-SOFT Software Engineering Notes, 9(3):42{48, 1984. Proc. of the ACM SIG-SOFT/SIGPLAN Software Engineering Symposium on Practical Software De-velopment Environments, Pittsburgh, Penn.[SAD94]C. Santos, S. Abiteboul, and C. Delobel. Virtual Schemas and Bases. InJ. Bubenko M. Jarke and K. Je erey, editors, Proc. of the 4th Int. Conf. onExtending Database Technology, Cambridge, UK, volume 779 of Lecture Notesin Computer Science, pages 81{94. Springer, 1994.[Sch91]A. Schurr. Operationales Spezi zieren mit programmierten Graphersetzungssys-temen. PhD thesis, RWTH Aachen, 1991.[SS95]S. Sachweh and W. Schafer. Version Management for tightly integrated SoftwareEngineering Environments. In M. S. Verrall, editor, Proc. of the 7th Interna-tional Conference on Software Engineering Environments, Nordwijkerhout, TheNetherlands, pages 21{31. IEEE Computer Society Press, 1995.[Tho89]I. Thomas. Tool Integration in the PACT Environment. In Proc. of the 11th Int.Conf. on Software Engineering, Pittsburg, Penn., pages 13{22. IEEE ComputerSociety Press, 1989.20